Scriptaculous or Scriptastrophe?

When I was asked if there was something that I would like to write for this opinion piece, I knew immediately what that topic would be. To say it is a personal bugbear of mine is an understatement, but it also feels, sometimes, as if I'm the only person who has this opinion. Surely I can't be alone with this? And just what is this annoyance that I seem to be carrying around with me like some heavy burden? 

The title of the piece should give at least an idea about the topic, that being scripts, or more specifically JavaScript. And a lot of it is related to my place of work that, like many large organisations, has firewalls, filters and all manner of other security measures in place to stop the likelihood of viruses carrying across to the internal network. But the problem is not just me having issues with how things work or don't work at my place of employment but rather that it points to a wider problem that exists in the way that coders/developers are approaching tasks and the effects they might have on people browsing in similar environments.

So here is the problem – people are reaching for JavaScript libraries to solve all manner of ills because it's an easy route that's tried, tested and often well documented. It's also far easier than trying to build something from scratch. But more often than not, people are plugging in the entire library with all the interdependencies but may only be using 5% of what it can do. That's a whole lot of download for nothing but that's not the biggest problem, in my opinion.

Some of the JavaScript functions produce less than perfect results, with accessibility being one of the casualties along the way. In many cases, it would be easy enough to hand-code a solution that works for users without JavaScript enabled and to apply the 'bells and whistles' version as a layer on top for those that do have the capability or desire for the JavaScript version. It's a methodology that comes under the general banner of 'Progressive Enhancement', but in terms of scripting it's known as Unobtrusive JavaScript – unobtrusive because it's not required by default and only kicks in if all criteria are satisfied, thus adding a 'bonus' layer on top. However, in most cases the features offered by off-the-shelf JavaScript libraries are completely reliant on the ability to run JavaScript and don't work unobtrusively. 

And there's AJAX – buzzword of the moment and web accessibility's latest foe. It's getting easier and easier to implement AJAX solutions thanks partly to libraries that take away the pain of implementation and things like .NET controls that make it as simple as dragging and dropping. There is no automatic Progressive Enhancement here – all the eggs are in that one basket and if it doesn't work, there's usually no fallback (Jeremy Keith coined the phrase 'Hijax', describing a methodology whereby you provide a default version that works without JavaScript but if the right conditions apply, the AJAX behaviour hijacks the default behaviour).

So, at this point I'll return to my issues with libraries and my place of work. These days, every time a site 'upgrades' and starts using a JavaScript library, the site invariably stops working because there are portions of the code that get blocked by the firewall. Things like 'eval' statements, calls to ActiveX objects (that may never be called, but it's in there nonetheless) and so on, so they're shown the door. "You, out! You look dodgy!"

To summarise, I'm not saying "don't use libraries", and I'm not saying "don't use JavaScript", but what I am suggesting is that you question "do I need a library to do this or could I create it myself more succinctly?". And whether you do opt for a library or not, please, please do make sure that you put in the necessary checks to ensure that your scripts will run – simply checking that JavaScript is enabled is not enough by itself. Instead, test for incremental successful outcomes along the way, rather than making one larger assumption.